Tái tạo Tĩnh Gia tăng của Next.js: Các Trang web Tĩnh Động cho Khán giả Toàn cầu

Trong bối cảnh phát triển web không ngừng thay đổi, việc mang lại trải nghiệm người dùng nhanh như chớp trong khi vẫn giữ cho nội dung tươi mới và năng động là một thách thức hàng đầu. Tạo trang tĩnh (SSG) truyền thống mang lại hiệu suất đáng kinh ngạc nhưng thường gặp khó khăn trong việc đáp ứng nội dung được cập nhật thường xuyên. Ngược lại, kết xuất phía máy chủ (SSR) cung cấp tính năng động nhưng có thể gây ra độ trễ. Next.js, một framework React hàng đầu, đã kết nối khoảng cách này một cách thanh lịch với tính năng đổi mới của mình: Tái tạo Tĩnh Gia tăng (ISR). Cơ chế mạnh mẽ này cho phép các nhà phát triển xây dựng các trang web tĩnh mang lại cảm giác năng động, cung cấp những gì tốt nhất của cả hai thế giới cho khán giả toàn cầu.

Hiểu về Nhu cầu của Trang web Tĩnh Động

Trong nhiều thập kỷ, các trang web đã hoạt động trên một phổ từ hoàn toàn tĩnh đến hoàn toàn động. Tạo trang Tĩnh (SSG) tiền kết xuất mọi trang tại thời điểm xây dựng, mang lại thời gian tải cực nhanh và SEO xuất sắc. Tuy nhiên, đối với nội dung thay đổi thường xuyên – chẳng hạn như các bài báo, cập nhật sản phẩm thương mại điện tử hoặc các dòng tin trên mạng xã hội – SSG yêu cầu xây dựng lại và triển khai lại toàn bộ trang web mỗi khi nội dung được cập nhật, điều này thường không thực tế và tốn thời gian. Hạn chế này làm cho SSG không phù hợp với nhiều ứng dụng trong thế giới thực có nhu cầu nội dung thời gian thực hoặc gần thời gian thực.

Mặt khác, Kết xuất phía Máy chủ (SSR) kết xuất các trang trên máy chủ cho mỗi yêu cầu. Mặc dù điều này đảm bảo nội dung luôn được cập nhật, nó lại làm tăng tải cho máy chủ và có thể dẫn đến thời gian tải trang ban đầu chậm hơn do máy chủ phải xử lý yêu cầu. Đối với khán giả toàn cầu ở các vị trí địa lý và điều kiện mạng khác nhau, SSR có thể làm trầm trọng thêm sự chênh lệch về hiệu suất.

Kịch bản lý tưởng cho nhiều ứng dụng web hiện đại là một trang web tận dụng các lợi ích về hiệu suất của các tệp tĩnh nhưng cũng có thể phản ánh thông tin mới nhất ngay khi có sẵn. Đây chính là điểm mà Tái tạo Tĩnh Gia tăng của Next.js tỏa sáng.

Tái tạo Tĩnh Gia tăng (ISR) là gì?

Tái tạo Tĩnh Gia tăng (ISR) là một tính năng trong Next.js cho phép bạn cập nhật các trang tĩnh sau khi trang web đã được xây dựng và triển khai. Không giống như SSG truyền thống, vốn yêu cầu xây dựng lại toàn bộ để phản ánh các thay đổi nội dung, ISR cho phép bạn tái tạo các trang riêng lẻ trong nền mà không làm gián đoạn trải nghiệm người dùng hoặc yêu cầu triển khai lại toàn bộ trang web. Điều này đạt được thông qua một cơ chế tái xác thực mạnh mẽ.

Khi một trang được tạo bằng ISR, Next.js sẽ phục vụ một tệp HTML tĩnh. Khi người dùng yêu cầu trang đó sau một khoảng thời gian nhất định, Next.js có thể âm thầm tái tạo trang trong nền. Người dùng đầu tiên yêu cầu trang sau khoảng thời gian tái xác thực có thể nhận được phiên bản cũ, đã được lưu trong bộ nhớ đệm, trong khi những người dùng tiếp theo sẽ nhận được phiên bản mới được tạo, đã cập nhật. Quá trình này đảm bảo rằng trang web của bạn vẫn hoạt động hiệu quả đối với hầu hết người dùng trong khi dần dần cập nhật nội dung.

Cách ISR Hoạt động: Cơ chế Tái xác thực

Cốt lõi của ISR nằm ở tính năng tái xác thực (revalidation) của nó. Khi bạn xác định một trang với ISR, bạn chỉ định một thời gian revalidate (tính bằng giây). Thời gian này xác định tần suất Next.js nên cố gắng tái tạo trang cụ thể đó trong nền.

Hãy cùng phân tích quy trình:

1. Thời điểm Xây dựng: Trang được tạo tĩnh tại thời điểm xây dựng, giống như SSG thông thường.
2. Yêu cầu Đầu tiên: Một người dùng yêu cầu trang. Next.js phục vụ tệp HTML đã được tạo tĩnh.
3. Bộ nhớ đệm Hết hạn: Sau khi khoảng thời gian revalidate đã chỉ định trôi qua, bộ nhớ đệm của trang được coi là cũ.
4. Yêu cầu Tiếp theo (Cũ): Người dùng tiếp theo yêu cầu trang sau khi bộ nhớ đệm đã hết hạn sẽ nhận được phiên bản *cũ*, nhưng vẫn được lưu trong bộ nhớ đệm. Điều này rất quan trọng để duy trì hiệu suất.
5. Tái xác thực trong Nền: Đồng thời, Next.js kích hoạt việc tái tạo trang trong nền. Quá trình này bao gồm việc tìm nạp dữ liệu mới nhất và kết xuất lại trang.
6. Cập nhật Bộ nhớ đệm: Sau khi quá trình tái tạo trong nền hoàn tất, phiên bản mới, đã cập nhật của trang sẽ thay thế phiên bản cũ trong bộ nhớ đệm.
7. Yêu cầu Kế tiếp: Người dùng tiếp theo yêu cầu trang sẽ nhận được phiên bản mới được tạo, đã cập nhật.

Quá trình cập nhật theo từng giai đoạn này đảm bảo rằng trang web của bạn vẫn có tính sẵn sàng cao và hiệu suất tốt, ngay cả khi nội dung đang được làm mới.

Các Khái niệm Chính:

• revalidate: Đây là tham số chính được sử dụng trong getStaticProps để kích hoạt ISR. Nó nhận một số đại diện cho giây.
• Stale-While-Revalidate: Đây là chiến lược lưu vào bộ nhớ đệm cơ bản. Người dùng nhận được nội dung cũ (đã lưu trong bộ nhớ đệm) ngay lập tức trong khi nội dung mới đang được tạo trong nền.

Triển khai ISR trong Next.js

Việc triển khai ISR trong ứng dụng Next.js của bạn rất đơn giản. Bạn thường cấu hình nó trong hàm getStaticProps của mình.

Ví dụ: Một Bài đăng Blog với Cập nhật Thường xuyên

Hãy xem xét một blog nơi các bài đăng có thể được cập nhật với các chỉnh sửa nhỏ hoặc thông tin mới. Bạn muốn những cập nhật này được phản ánh tương đối nhanh chóng, nhưng không nhất thiết phải ngay lập tức cho mọi người dùng.

Đây là cách bạn sẽ cấu hình ISR cho một trang bài đăng blog:

            // pages/posts/[slug].js

import { useRouter } from 'next/router'

export async function getStaticPaths() {
  // Fetch all post slugs to pre-render them at build time
  const posts = await fetch('https://your-api.com/posts').then(res => res.json());

  const paths = posts.map((post) => ({
    params: { slug: post.slug },
  }));

  return {
    paths,
    fallback: 'blocking', // or true, or false depending on your needs
  };
}

export async function getStaticProps({ params }) {
  // Fetch the specific post data for the current slug
  const post = await fetch(`https://your-api.com/posts/${params.slug}`).then(res => res.json());

  return {
    props: {
      post,
    },
    // Enable ISR: Revalidate this page every 60 seconds
    revalidate: 60, // In seconds
  };
}

function PostPage({ post }) {
  const router = useRouter();

  // If the page is not yet generated, this will be displayed
  if (router.isFallback) {
    return 
Loading...
;
  }

  return (
    

      
{post.title}
      
{post.content}
      {/* Other post details */}
    
  );
}

export default PostPage;

            

              
                Copy
              
            
          

Trong ví dụ này:

• getStaticPaths được sử dụng để tiền kết xuất một tập hợp các đường dẫn (slug của bài đăng blog) tại thời điểm xây dựng.
• getStaticProps tìm nạp dữ liệu cho một bài đăng cụ thể và quan trọng là đặt thuộc tính revalidate: 60. Điều này yêu cầu Next.js tái tạo trang này mỗi 60 giây trong nền.
• fallback: 'blocking' đảm bảo rằng nếu người dùng yêu cầu một đường dẫn chưa được tiền kết xuất tại thời điểm xây dựng, máy chủ sẽ đợi để tạo trang (trên máy chủ) và sau đó phục vụ nó. Điều này thường được sử dụng với ISR.

Hiểu về `fallback` với ISR

Tùy chọn fallback trong getStaticPaths đóng một vai trò quan trọng khi sử dụng ISR:

• fallback: false: Các đường dẫn không được trả về từ getStaticPaths sẽ dẫn đến trang 404. Điều này hữu ích cho các trang web nơi tất cả các tuyến động đều được biết tại thời điểm xây dựng.
• fallback: true: Các đường dẫn không được trả về từ getStaticPaths sẽ cố gắng được tạo ở phía máy khách trước (hiển thị trạng thái đang tải). Sau khi tạo, trang được lưu vào bộ nhớ đệm. Điều này có thể tốt cho hiệu suất nếu bạn có nhiều tuyến động.
• fallback: 'blocking': Các đường dẫn không được trả về từ getStaticPaths sẽ được kết xuất phía máy chủ trong yêu cầu đầu tiên. Điều này có nghĩa là người dùng sẽ đợi cho đến khi trang được tạo. Các yêu cầu tiếp theo sẽ phục vụ trang tĩnh đã được lưu trong bộ nhớ đệm cho đến khi nó được tái xác thực. Đây thường là tùy chọn được ưu tiên cho ISR vì nó đảm bảo một tệp tĩnh luôn được phục vụ sau yêu cầu đầu tiên, duy trì hiệu suất.

Đối với ISR, fallback: 'blocking' hoặc fallback: true thường phù hợp hơn, cho phép các tuyến động mới được tạo theo yêu cầu và sau đó được hưởng lợi từ ISR.

Lợi ích của ISR đối với Khán giả Toàn cầu

Những ưu điểm của ISR đặc biệt rõ rệt khi phục vụ khán giả toàn cầu:

1. Tăng cường Hiệu suất trên các Vùng địa lý

Bằng cách phục vụ các tệp tĩnh đã được tiền kết xuất, ISR đảm bảo rằng người dùng, bất kể vị trí của họ, đều trải nghiệm thời gian tải nhanh. Chiến lược stale-while-revalidate có nghĩa là ngay cả trong quá trình cập nhật nội dung, hầu hết người dùng vẫn sẽ nhận được các trang đã được lưu trong bộ nhớ đệm, tải nhanh, giảm thiểu tác động của độ trễ mạng và thời gian xử lý của máy chủ. Điều này rất quan trọng để duy trì sự tương tác với người dùng ở các khu vực có cơ sở hạ tầng internet kém phát triển hơn.

2. Nội dung Gần như Thời gian thực mà không cần Gánh nặng của SSR

Đối với nội dung cần được cập nhật thường xuyên nhưng không yêu cầu độ chính xác tuyệt đối theo thời gian thực (ví dụ: giá cổ phiếu, tin tức, tình trạng còn hàng của sản phẩm), ISR cung cấp một sự thỏa hiệp hoàn hảo. Bạn có thể đặt một khoảng thời gian tái xác thực ngắn (ví dụ: 30-60 giây) để đạt được các bản cập nhật gần như thời gian thực mà không phải lo ngại về khả năng mở rộng và hiệu suất liên quan đến việc SSR liên tục.

3. Giảm Tải và Chi phí Máy chủ

Vì các trang chủ yếu được phục vụ từ một CDN (Mạng phân phối Nội dung) hoặc dịch vụ lưu trữ tệp tĩnh, tải trên các máy chủ gốc của bạn được giảm đáng kể. ISR chỉ kích hoạt việc tái tạo phía máy chủ trong khoảng thời gian tái xác thực, dẫn đến chi phí lưu trữ thấp hơn và khả năng mở rộng được cải thiện. Đây là một lợi thế đáng kể cho các ứng dụng có lượng truy cập cao từ các địa điểm toàn cầu đa dạng.

4. Cải thiện Thứ hạng SEO

Các trình thu thập thông tin của công cụ tìm kiếm ưa thích các trang web tải nhanh. Khả năng của ISR trong việc cung cấp tài sản tĩnh một cách nhanh chóng và hiệu quả góp phần tích cực vào SEO. Hơn nữa, bằng cách giữ cho nội dung luôn mới, ISR giúp các công cụ tìm kiếm lập chỉ mục thông tin mới nhất của bạn, cải thiện khả năng khám phá cho khán giả toàn cầu của bạn.

5. Đơn giản hóa Quản lý Nội dung

Người tạo nội dung và quản trị viên có thể cập nhật nội dung mà không cần phải kích hoạt việc xây dựng lại toàn bộ trang web. Một khi nội dung được cập nhật trong CMS của bạn và được quá trình ISR tìm nạp, các thay đổi sẽ được phản ánh trên trang web sau chu kỳ tái xác thực tiếp theo. Điều này hợp lý hóa quy trình xuất bản nội dung.

Khi nào Nên sử dụng ISR (và Khi nào Không)

ISR là một công cụ mạnh mẽ, nhưng giống như bất kỳ công nghệ nào, nó được sử dụng tốt nhất trong bối cảnh phù hợp.

Các Trường hợp Sử dụng Lý tưởng cho ISR:

• Trang Sản phẩm Thương mại Điện tử: Hiển thị thông tin sản phẩm, giá cả và tình trạng còn hàng có thể thay đổi trong ngày.
• Trang web Tin tức và Bài báo: Giữ cho các bài báo được cập nhật với tin tức nóng hổi hoặc các chỉnh sửa nhỏ.
• Bài đăng trên Blog: Cho phép cập nhật và sửa lỗi nội dung mà không cần triển khai lại toàn bộ.
• Danh sách Sự kiện: Cập nhật lịch trình, địa điểm hoặc tình trạng còn vé của sự kiện.
• Trang Nhóm hoặc Danh bạ: Phản ánh những thay đổi nhân sự gần đây.
• Các Widget trên Bảng điều khiển: Hiển thị dữ liệu được cập nhật thường xuyên mà không cần độ chính xác đến từng mili giây.
• Các Trang Tài liệu: Cập nhật tài liệu khi các tính năng hoặc bản vá mới được phát hành.

Khi ISR có thể không phải là Lựa chọn Tốt nhất:

• Nội dung Cá nhân hóa Cao: Nếu mỗi người dùng thấy nội dung độc nhất dựa trên hồ sơ hoặc phiên của họ, SSR hoặc tìm nạp phía máy khách có thể phù hợp hơn. ISR tốt nhất cho nội dung phần lớn giống nhau cho tất cả người dùng nhưng cần cập nhật định kỳ.
• Dữ liệu Chính xác đến Từng Mili giây: Đối với các ứng dụng yêu cầu dữ liệu thời gian thực tuyệt đối (ví dụ: bảng giá cổ phiếu trực tiếp, hệ thống đấu giá thời gian thực), khoảng thời gian tái xác thực của ISR có thể gây ra sự chậm trễ không thể chấp nhận được. Trong những trường hợp này, WebSockets hoặc Server-Sent Events (SSE) có thể phù hợp hơn.
• Nội dung Không bao giờ Thay đổi: Nếu nội dung của bạn là tĩnh và không bao giờ cần cập nhật sau thời điểm xây dựng, SSG truyền thống là đủ và đơn giản hơn.

Các Chiến lược và Cân nhắc ISR Nâng cao

Mặc dù việc triển khai cơ bản của ISR rất đơn giản, có những chiến lược và cân nhắc nâng cao để tối ưu hóa việc sử dụng nó, đặc biệt là đối với khán giả toàn cầu.

1. Chiến lược Vô hiệu hóa Bộ nhớ đệm (Ngoài Thời gian)

Mặc dù tái xác thực dựa trên thời gian là cách tiếp cận mặc định và phổ biến nhất, Next.js cung cấp các cách để kích hoạt tái xác thực theo chương trình. Điều này vô giá khi bạn muốn nội dung được cập nhật ngay khi một sự kiện xảy ra (ví dụ: một webhook CMS kích hoạt cập nhật).

Bạn có thể sử dụng hàm res.revalidate(path) trong một hàm serverless hoặc tuyến API để tái xác thực một trang cụ thể theo cách thủ công.

            // pages/api/revalidate.js

export default async function handler(req, res) {
  // Check for a secret token to ensure only authorized requests can revalidate
  if (req.query.secret !== process.env.REVALIDATE_SECRET) {
    return res.status(401).json({ message: 'Invalid token' });
  }

  try {
    // Revalidate the specific post page
    await res.revalidate('/posts/my-updated-post');
    return res.json({ revalidated: true });
  } catch (err) {
    // If there was an error, Next.js will continue to serve the stale page
    return res.status(500).send('Error revalidating');
  }
}

            

              
                Copy
              
            
          

Tuyến API này có thể được gọi bởi CMS của bạn hoặc một dịch vụ khác bất cứ khi nào nội dung liên quan đến /posts/my-updated-post được thay đổi.

2. Các Tuyến động và `fallback` trong Thực tế

Việc chọn tùy chọn fallback phù hợp là rất quan trọng:

• Đối với các blog có số lượng bài đăng có thể dự đoán được xuất bản tại thời điểm xây dựng, fallback: false có thể là đủ, nhưng sau đó các bài đăng mới sẽ không thể truy cập được cho đến lần xây dựng tiếp theo.
• Nếu bạn dự đoán có nhiều bài đăng hoặc sản phẩm mới được thêm vào thường xuyên, fallback: 'blocking' thường được ưu tiên với ISR. Nó đảm bảo rằng các trang mới được tạo theo yêu cầu, hoàn toàn tĩnh sau yêu cầu đầu tiên, và sau đó được hưởng lợi từ ISR cho các lần cập nhật tiếp theo.

3. Chọn Thời gian Tái xác thực Phù hợp

Thời gian revalidate nên là một sự cân bằng:

• Thời gian ngắn hơn (ví dụ: 10-60 giây): Phù hợp với nội dung thay đổi rất thường xuyên, như điểm số trực tiếp hoặc mức tồn kho sản phẩm. Hãy lưu ý đến việc tăng tải máy chủ và chi phí yêu cầu API.
• Thời gian dài hơn (ví dụ: 300-3600 giây, hoặc 5-60 phút): Lý tưởng cho nội dung cập nhật ít thường xuyên hơn, như bài đăng blog hoặc tin tức. Điều này tối đa hóa lợi ích của việc lưu trữ tĩnh.

Hãy xem xét mức độ chấp nhận của khán giả đối với nội dung cũ và tần suất cập nhật dữ liệu của bạn khi đặt giá trị này.

4. Tích hợp với Headless CMS

ISR hoạt động đặc biệt tốt với các Hệ thống Quản lý Nội dung không đầu (Headless CMS) như Contentful, Strapi, Sanity, hoặc WordPress (với API REST của nó). Headless CMS của bạn có thể kích hoạt webhook khi nội dung được xuất bản hoặc cập nhật, sau đó có thể gọi tuyến API Next.js của bạn (như đã trình bày ở trên) để tái xác thực các trang bị ảnh hưởng. Điều này tạo ra một quy trình làm việc tự động, mạnh mẽ cho nội dung tĩnh động.

5. Hành vi Lưu trữ của CDN

Next.js ISR hoạt động cùng với CDN của bạn. Khi một trang được tạo, nó thường được phục vụ từ CDN. Thời gian revalidate ảnh hưởng đến thời điểm các máy chủ biên của CDN coi bộ nhớ đệm là cũ. Nếu bạn đang sử dụng một nền tảng được quản lý như Vercel hoặc Netlify, họ xử lý phần lớn sự tích hợp này một cách liền mạch. Đối với các thiết lập CDN tùy chỉnh, hãy đảm bảo CDN của bạn được cấu hình để tôn trọng các tiêu đề bộ nhớ đệm của Next.js.

Các Ví dụ Toàn cầu và Thực tiễn Tốt nhất

Hãy xem cách ISR có thể được áp dụng trong bối cảnh toàn cầu:

• Công cụ Tổng hợp Tin tức Toàn cầu: Hãy tưởng tượng một trang web tổng hợp tin tức từ các nguồn quốc tế khác nhau. ISR có thể đảm bảo rằng các tiêu đề và tóm tắt bài viết được cập nhật vài phút một lần, cung cấp cho người dùng trên toàn thế giới thông tin mới nhất mà không làm quá tải máy chủ. Thời gian revalidate có thể được đặt thành 300 giây.
• Nền tảng Thương mại Điện tử Quốc tế: Một nhà bán lẻ trực tuyến bán sản phẩm trên toàn cầu có thể sử dụng ISR cho các trang sản phẩm. Khi mức tồn kho hoặc giá của một sản phẩm được cập nhật (có thể bị ảnh hưởng bởi tình trạng còn hàng theo khu vực hoặc biến động tiền tệ), ISR có thể đảm bảo những thay đổi này được phản ánh trên toàn trang web trong vòng vài phút, với revalidate là 60 giây.
• Các Trang web Nội dung Đa ngôn ngữ: Đối với các trang web cung cấp nội dung bằng nhiều ngôn ngữ, mỗi phiên bản đã dịch có thể được hưởng lợi từ ISR. Nếu một phần nội dung cốt lõi được cập nhật, tất cả các phiên bản được bản địa hóa có thể được tái xác thực một cách không đồng bộ.
• Bán vé Sự kiện Toàn cầu: Đối với các sự kiện quốc tế lớn, tình trạng còn chỗ ngồi hoặc lịch trình sự kiện có thể thay đổi thường xuyên. ISR có thể giữ cho các trang này được cập nhật, phục vụ nội dung tĩnh, nhanh cho người dùng mua vé từ các múi giờ khác nhau.

Các Thực tiễn Tốt nhất Toàn cầu:

• Xem xét Múi giờ trong Tái xác thực: Mặc dù revalidate là một khoảng thời gian cố định, hãy lưu ý đến thời điểm cập nhật nội dung chính của bạn diễn ra. Việc điều chỉnh tái xác thực với thời gian cập nhật nội dung cao điểm có thể có lợi.
• Kiểm tra Hiệu suất từ các Vùng khác nhau: Sử dụng các công cụ như Google PageSpeed Insights hoặc WebPageTest để kiểm tra hiệu suất trang web của bạn từ các vị trí địa lý khác nhau.
• Theo dõi Việc sử dụng và Chi phí API: Nếu ISR của bạn phụ thuộc vào các API bên ngoài, hãy theo dõi việc sử dụng chúng và đảm bảo bạn không vượt quá giới hạn tỷ lệ hoặc phát sinh chi phí không mong muốn với việc tái xác thực thường xuyên.
• Sử dụng CDN Toàn cầu: Tận dụng Mạng phân phối Nội dung có sự hiện diện toàn cầu rộng rãi để đảm bảo các tài sản tĩnh của bạn được phục vụ từ các vị trí gần với người dùng của bạn.

Những Cạm bẫy Phổ biến và Cách tránh

Mặc dù mạnh mẽ, ISR có thể dẫn đến hành vi không mong muốn nếu không được triển khai cẩn thận:

• Tái xác thực Quá mức: Đặt revalidate thành các giá trị rất thấp (ví dụ: 1 giây) có thể làm mất đi lợi ích của việc tạo tĩnh và gây tải quá mức cho các nguồn dữ liệu và máy chủ của bạn, về cơ bản hoạt động giống như SSR nhưng với cơ chế phân phối có thể kém dự đoán hơn.
• Bỏ qua các Trạng thái `fallback`: Không xử lý đúng trạng thái `router.isFallback` có thể dẫn đến trải nghiệm người dùng bị hỏng khi các tuyến động mới đang được tạo.
• Lỗi Logic Vô hiệu hóa Bộ nhớ đệm: Nếu logic vô hiệu hóa bộ nhớ đệm theo chương trình của bạn bị lỗi, nội dung của bạn có thể trở nên cũ và không bao giờ cập nhật, hoặc nó có thể cập nhật không chính xác. Hãy kiểm tra kỹ lưỡng các tuyến API tái xác thực của bạn.
• Lỗi Tìm nạp Dữ liệu: Nếu getStaticProps không tìm nạp được dữ liệu trong quá trình tái xác thực, dữ liệu cũ sẽ tiếp tục được phục vụ. Hãy triển khai xử lý lỗi và ghi nhật ký mạnh mẽ trong các hàm tìm nạp dữ liệu của bạn.
• Quên `getStaticPaths`:** Nếu bạn đang sử dụng các tuyến động với ISR, bạn *phải* xuất `getStaticPaths` để cho Next.js biết các đường dẫn nào cần tiền kết xuất và cách xử lý các đường dẫn không xác định.